that seems nice (solving #18)

not sure but could we avoid normalizing if possible?
ie if there's already a match with unnormalized maybe we can avoid normalizing.

I'm thinking of something better: maybe when render() is called we should store some this.renderedHtml = html property, and then use it in shouldComponentUpdate instead of node.innerHtml? this would probably fix the problem

Not sure but I also think calling innerHtml has a cost

@slorber The whole idea of this component is that shouldComponentUpdate will return false, and we're skipping render calls. Hence we must compare the input prop to the inner HTML in the live DOM. I pushed another change to bypass the normalization though, in cases where the browser does not reformat.

Looks like an equally valid workaround to me. I however do not see anymore why we need such a workaround at all. Maybe I am too sleepy, but the 'something better' solution slorber suggested sounds sound to me now.

The reason is that browser reformatting should not be a problem at all. Assume we render some html, and the browser reformats it. There are then two ways the html prop may change:

1. By the user's edit, in which case nextProps.html already incorporates the browser's reformatting and the nextProps.html !== this.htmlEl.innerHTML test adequately cancels the rerender.
2. Programatically, in which case we have to rerender anyway, if it is different from what we rendered last time.

So just adding a check whether the html is any different from last time should be enough. We do not even need to store it in this.renderedHtml or anything, since the previous this.props is still available in shouldComponentUpdate. I will put it in a PR. :)

Hi all! I don't use this project myself anymore, and don't really have time for it at the moment. You may all be more knowledgeable about this module than I am.

Do some of you have the time and goodwill to help me maintain this repo on github?

same for me unfortunatly I can only provide feedback from my own experience

Heh, our project ended up taking pieces of this code and adapting it. We had some unfortunate interactions that didn't fit this model.

any example? maybe you are not alone (I don't use react-contenteditable either)

So, is this PR outdated by #27 ? Can I close it ?

If I am not mistaken this should indeed be outdated by #27.

Regarding maintainance, I could try help out at least while using the module in my own project.